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Abstract: RUP (Reasoning Utility Package) is a collection of procedures for performing various 

computations relevant to automated reasoning. RUP contains a truth maintenance system (TMS) which can 
be used to perform simple propositional deduction (unit clause resolution), to record justifications, to track 
down underlying assumptions, and to perform incremental modifications when premises arc changed. This 
TMS can be used with an automatic premise controller which automatically retracts "assumptions" before 
"solid facts" when contradictions arise and searches for the most solid proof of an assertion. RUP also 
contains a procedure for efficiently computing all the relevant consequences; of any set of equalities between 
ground terms, A related utility computes "substitution simplifications" of terms under an arbitrary set of 
unqualified equalities and a user defined simplicity order. RUP also contains demon writing macros which 
allow one to write PLANNKR like demons that trigger on various types of events in the data base. Finally 
there is a utility for reasoning about partial orders and arbitrary transitive relations. In writing all of these 
utilities an attempt has been made to provide a maximally flexible environment for automated reasoning. 
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1. INTRODUCTION 



RUP (Reasoning Utility Package) is a collection of utilities relevant to automated reasoning. RUP 
contains a truth maintenance system (TMS) which can be used to perform simple propositional deduction 
(unit clause resolution), to record justifications, to track down underlying assumptions, and to perform 
incremental modifications when premises are changed. RUP also provides a fast system for performing 
deductions concerning equalities. The equality system contains routines which "intern" expressions. This 
system also performs all deductions which can be made purely via substitution of equals for equals and can 
simplify terms under a large class of simplicity orderings. RUP also contains mechanisms for writing 
PLANNER-likc demons. The demons created via this package can be compiled as ordinary lisp functions in 
which the pattern matching mechanism is open coded into the definition of each such demonic function. 

In designing the RUP environment an attempt has been made to maximize the flexibility of the utilities 
and allow them to interact effectively with user defined systems. Thus there are many "hooks'* which allow 
the user to modify RUP in different ways. For example hooks are provided for installing user defined 
backtracking functions and user defined pattern directed invocation mechanism. There is also a general 
control methodology adopted in RUP which associates queues with invariants. The demonic triggering 
mechanisms provided by RUP allow the user to define his own queues and invariants and to maintain those 
invariants by having forms queued demonically when an invariant is violated. RUP provides a simple data 
base in the form of interned expressions but users typically define their own data structures and define 
/"""^ invariants which associate their data structures with those provided by RUP. 

This document describes' the major functions in RUP and examples of their use. The description of each 
function is prefaced by the name of the function in bold letters followed by the list of arguments taken by that 
function. RUP is implemented in both LISP Machine LISP and in MACLISP. There are two versions of the 
TMS one which implements a semi-automatic certainty based premise controller and one which leaves 
premise control entirely to the user. One can load RUP into LISP by loading whichever of the following files 
is appropriate (the files reside on MIT-AI): 

AI:RUP;RUP > LISP machine RUP without premise controller 

AI:RUP;RUPP > LISP machine RUP with semi-automatic premise control 

AI:RUP;MRUP > MACLISP RUP without premise controller 

AI:RUP;MRUPP > MACLISP RUP with semi-automatic premise control 

The LISP machine versions loads into the package RUP and all symbols in this manual which do not 
have an explicit package prefix reside in die RUP package. In the MACLISP version package prefixes are 
simply interpreted as part of the character name. 
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2. SOME SIMPLE SCENARIOS 

This section is intended for first time users who want to use RUP in the most straightforward manner 
possible. A series of scenarios is presented each of which is intended to demonstrate some feature of the top 
level RUP environment. The reader should be cautioned against just reading these scenarios and not reading 
the remainder of the manual. There arc many utilities which are not demonstrated in these scenarios. 
Furthermore the scenarios emphasize the use of RUP as a programming language and leave out the important 
view of RUP as a utility package, 

The first scenario demonstrated the simple propositional reasoning facilities and the explanation 
generation mechanisms. 

The second scenario demonstrates how the simple propositional deduction mechanisms can be extended 
with a refutation mechanism invoked by the top level function try-to-show while the third scenario shows die 



Scenario 1. 

(assert ''(:-> p q)) 

(assert *(:-> q r)) 

(assert *p) 

(why *r) 

"R IS :TRUE FROM:" 

"1 Q IS :TRUE" 

"2 ( :-> Q R) IS :TRUE" 

(why 1) 

"Q IS :TRUE FROM:" 

"1 P IS :TRUE" 

"2 (:-> P Q) IS :TRUE" 

(why 1) 

"P IS :TRUE AS A PREMISE" 

(why 0) 

"Q IS :TRUE FROM:" 

"1 P IS :TRUE" 

"2 (:-> P Q) IS :TRUE" 

(why 0) 

"R IS :TRUE FROM:" 

"1 Q IS :TRUE" 

"2 (:-> Q R) IS :TRUE" 

(why 2) 

"(:-> Q R) IS :TRUE AS A PREMISE" 
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substitution capabilities of the system. 

The final scenario demonstrates the use of simple demons. Of course demons are not normally defined 
by typing them into the top level RUP environment. Each pattern directed demon has a trigger pattern, a 
triggering condition keyword (such as :intern) and a queue on which the invocation of the body is placed 
when the triggering occurs. The symbol *basic-quGues* is bound to a list of queues which are emptied by 
certain top level functions such as assert and why. The body of a demon may be any list of LISP expressions. 
The macro Iconst constructs clauses in the TMS corresponding to the assertions it is given. Constructing a 
clause in the TMS is different from asserting an implication; specifically clauses never appear in explanations 
while asserted implications do. 



Scenario 2. 

^"■n (assert '(:-> p r)) 

(assert ' ( : -> q r)) 

(assert *(:or p q)) 



(why *r) 

"I DON'T KNOW WHETHER OR NOT R IS :TRUE M 

( try-to-show *r) 



(why *r) 

"R IS :TRUE FROM:" 

"1 (:-> P R) IS :TRUE" 

"2 (:-> Q R) IS :TRUE" 

"3 (:0R P Q) IS :TRUE" 



Scenario 3, 



/*> 



(assert •(- (f a b) a)) 

(why •(« (f (f a b) b) a)) 

M (- (F (F A B) B) A) IS :TRUE FROM: 

"1 (■ (F A B) A) IS :TRUE" 
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_. Scenario 4. 



A 



(setq *user-queue* (make-f ifo) ) 

(setq *basic-queues* (append *basic-queues* (list *user-queue*))) 

(notice (intern (dog ?x)) *user-queue* 
(Iconst (:-> (dog ?x) (mammal ?x)))) 

(notice (intern (hawk ?x)) *user-queue* 
(Iconst (:-> (hawk ?x) (bird ?x)))) 

(notice (intern (mammal ?x)) *user-queue* 

(Iconst (:not (:and (mammal ?x) (bird ?x))))) 



(assert ' (dog f ido)) 

(why '(hawk fido)) 

"(HAWK FIDO) IS :FALSE FROM:" 

"1 (BIRD FIDO) IS :FALSE" 

(why 1) 

"(BIRD FIDO) IS :FALSE FROM:" 

"1 (MAMMAL FIDO) IS :TRUE" 

(why 1) 

"(MAMMAL FIDO) IS :TRUE FROM:" 

"1 (DOG FIDO) IS :TRUE" 

(why 1) 

"(DOG FIDO) IS :TRUE AS A PREMISE" 
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3. THE TRUTH MAINTENANCE SYSTEM 

A truth maintenance system is a utility which operates on an asscrtional data bctse (a collection of TMS 
nodes) and has at least the following four properties: 

1) It can perform some form of propositional deduction from propositional premises 
(propositional deduction does not involve quantification). 

2) It records justifications for deduced assertions and can generate explanations for those 
assertions. 

3) It can incrementally retract deductions when premises are retracted so that all "true" 
assertions in the data base arc either premises or follow logically from the premises. 

4) It can perform "dependency directed backtracking". That it to say that when a contradiction 
arises it can use the recorded justifications to track down the premises underlying that 
contradiction. Furthermore when one of these premises is retracted it can use die contradiction 
to deduce the negation of the retracted premise. 

This section describes the functionality of RUFs TMS in detail. The first part of this section describes 
the association between queues and invariants which is used in much of RUP. The second part describes the 
two basic data structures used in the TMS. The third describes the basic TMS invariants which form the major 
specifications for the functionality of the TMS. The fourth part describes the major functions defined in the 
TMS. The fifth part describes TMS demons. 

3.1. Queues and Invariants 

Much of RUP is specified by stating invariants which should hold in the RUP environment. Several of 
these invariants are associated with queues, such that for each violation of the invariant there is some entry on 
the queue that can be used to correct that violation. Thus when a queue has been emptied the invariant 
associated with that queue must hold. For example diere is a TMS invariant which says that for each 
contradiction in the TMS there is an entry on the queue *backtracking-imariant*. While there are many 
TMS invariants, die only user visible queue associated with these invariants is ^backtracking-invariant*. 
(There are other user visible queues which are associated with other RUP invariants.) The basic primitives for 
constructing and manipulating all RUP queues are described here. 
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make-fifoQ 

This function returns a new first in first out queue. 

fifo-push (item queue) 

This function pushes an item on a fifo queue. Each item on a queue must be a list of a 
function followed by a list of arguments. Thus a particular queue entry item can be "run" by 
evaluating: 

(apply (car item) (cdr item)) 

fifo-empty? (queue) 

Thus predicate is non-nil just in case the given queue is not empty. 

run-queues (queue-list) 

This function takes a list of queues and empties them by "running" the items on the 
queues. This function itcratively takes the next item of die first non-empty queue in the given 
list of queues and runs that item. Note that in running one item more items may be queued. 
Thus a queue which was empty at one iteration may not be empty on the next iteration. On each 
iteration this function takes the first item off die first non-empty queue. The function terminates 
when all queues are empty. 

The order of the queues in the given list of queues imposes a "priority" on die queues. 
Items on the second queue will only be run in environments in which die first queue is empty. 
Thus if diere is some invariant associated with the first queue items on the second queue will 
only be run in an environment in which that invariant is in force. 

*basic-queues* variable 

This variable is bound to a list of queues and can be passed as an argument to 
multi-fifo-empty. The default value of this variable is: 

(list *equality-invariants* *rup-top-level* *backtracking-invariant*) 

The variables *equality-invariants*, *rup-top-level*, and *baektracking-invariant* are all 

set to queues in the default RUP environment. 
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3.2. Nodes and Clauses 

There are two basic data structures used in the TMS: TMS-nodcs and clauses. 

3.2.1 TMS NODES 

TMS-node structure 

(defstruct (tms-node (:type :named-array)) 
assertion 
(truth ' :unknown) 
support 
true-noticers 
f al se-noticers 
change-noticers 
neg-clauses 
pos-clauses 
default 
default-cert 
certainty 

(node-plist (neons nil)) 
(node-extension (funcall *make-node-extension*)) ) 

The slots of tms-nodes is described below; 

r^ assertion A tnis-node is intended to represent a proposition or assertion of some form. The 

assertion slot is not used by the TMS directly but is intended to hold the name of the assertion. 
In RUP the assertion slot holds the term whose print name is the name of the assertion. Terms 
are described in the section on the equality system. 

truth This slot always contains one of the atoms runknown, :true and :false. 

support This slot is either nil or contains a clause which is the justification for the truth of this 
node. Only nodes whose truth is either :true or :false have non-nil support slots. This slot is 
described in more detail in the section on TMS invariants. 

true-noticers, false-noticers, and change-noticers These slots contain demons which are queued 
when certain events occur in the TMS. These slots are described in more detail in the section on 
tms noticers. 

neg-clauses For any TMS node n the neg-clauses of n is a list of all those clauses c such that the 
pair (n . :false) is a member of the clause-list of c. (See the description of clauses.) 

pos-clauses For any TMS node n the pos-clauses of n is a list of all those clauses c such that the 
f"^ pair (n . :true) is a member of the clause-list of c. (See the description of clauses.) 
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/^ default This slot is only used in the TMS with the semi-automatic premise controller. This slot 

is either nil or contains a default truth value which is cither :true or :false, This slot is described 
in more detail in the section on TMS invariants. 

default-cert This slot is only used in the TMS with the semi-automatic premise controller. If the 
default slot is non-nil then this slot contains an integer between the values of the special 
variables *min-ccrt* and *max-cert* inclusive. This slot is discussed further in the section on 
TMS invariants. 

certainty This slot is only used in die TMS with the semi-automatic premise controller. If the 
truth of the node is not :unkno\vn then this slot contains die minimum certainty of die premises 
which underly die truth of die node. 

nodc-plist This slot contains a disembodied property list (LISP Machine manual pp. 71-72) and 
is initialized to (neons nil). This allows die user to define properties which are not already 
structure slots. A new "slot" for TMS nodes can be defined as follows: 

(defmacro new-slot (node) 

'(get (node-plist ,node) *new-s1ot)) 

^"^ Since die node-plist slot is used internally In RUP it is important that the user not violate the 

conventions for property lists in using this slot. 

node-extension This slot is not used internally in RUP and is available for use by the user. The 
value of diis slot is initialized to (funcall *make-node-extcnsion*) so that the user can control the 
initial value. *make-no<le-extension* is inidalized to a function which always returns nil. It is 
intended that the user define his own structure which extends the node data structure' and 
initialized this slot to that structure which could be done as follows: 

(defstruct (node-extension) 
fl 
f2 

(defun extension-maker () 
(make-node-extension)) 

(setq *make-node-extension* (fsymeval 'extension-maker)) 
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3.2.2 CLAUSES 

A clause is a data structure which represents a logical disjunction. A clause should be thought of as 
representing a constraint which says that at least one of a particular collection of items must be true. The 
details of this data structure are described below. 

clause structure 

(defstruct (clause (:type :namod-array)) 
clause-list 
psat) 

clause-list This slot contains a list of pairs such that die car of each pair is a tins-node and the 
cdr of each pair is cither the atom :true or the atom :false. A given pair is said to be true if the 
truth of its car is the same as its cdr. Similarly a pair is said to be false if. the truth its car is the 
opposite of its cdr. For example if the truth of a node n is :falsc then the pair (n , :false) is said 
to be true while die pair (n . :true) is said to be false. Since the truth of a TMS node can be 
:unknown it can be the case that a given pair in the clause list is neither true or false. A clause 
should be thought of as a disjunction which says that not all of die pairs in its clause-list can be 
false. 

psat This slot always contains a number which is the number of pairs in the clause list which 
are not false. Any clause whose psat is is called a^ontradiction. A clause whose psat is 1 can be 
used as a justification for assigning a truth value to die node which is die car of die pair in the 
clause-list which is not false. 



3.2.3 SOME CONVENIENT MACROS 

The following macros are convenient for testing die truth of a node: 

true? (node) 

The form (true? node) macroexpands to (eq ':true (truth node)), 
false? (node) 

(false? node) = => (eq ':false (truth node)) 
unknown? (node) 

(unknown? node) = => (eq 'lunknown (truth node)) 
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3.3. The TMS Invariants 

There are three groups of invariants concerning the TMS data structures which are maintained by the 
TMS. The first group of invariants, die justification invariants, ensure that every deductions has a well 
founded justification (i.e. that the deduction performed by die system is sound). The second group of 
invariants, the deduction invariants, guarantee that deduction is closed under a simple deduction rule (which 
is equivalent to unit clause resolution). A final backtracking invariant can be used to ensure that the set of 
premises in the system is "consistent" in that no contradiction can be deduced using the TMS's deduction 
machinery. Some of the justification and deduction invariants only apply to the TMS with the semi-automatic 
premise controller. Only the backtracking invariant involves a user visible queue. 

3.3.1 THE JUSTIFICATION INVARIANTS 

Only nodes whose truth slot is either :truc or :false can have non-null support slots and when such a 
support slot is non-null it contains a clause which is the justification for the truth value of die supported node. 
Each clause should be thought of as a disjunction (sec the above description of the clause data structure). The 
basic idea behind justifications is that truth, value of the justified node (the value of its truth slot) follows 
logically from die justifying clause and the truth values of die other nodes in diat clause. All clauses are 
/*""% interpreted by the system as logical tautologies, thus while the truth values assigned to nodes can be retracted, 

clauses cannot be removed. Similarly, in generating explanations the system will list assignments of truth 
values to nodes but will not mention the existence of clauses. The interpretation of clauses as tautologies is 
described in more detail in [McAllester 80b]. A TMS node whose truth is either :true or :false (i.e. not 
runknown) but which does not have any supporting clause (i.e. its support slot is nil) will be called a premise. 

Local Support Invariant: This invariant states that die truth value which has been assigned to a 
supported node n follows logically from the clause which is the support of n and the truth values 
which have been assigned to the other nodes appearing in the clause. Specifically let n be any 
TMS node whose truth is eidier :true or :false and whose support is not nil. The support of n 
must contain a clause c such that the psat of c is 1 (there is exactly one pair in the clause list of c 
which is not false) and such that the pair in c which is not false contains n (the supported node). 

Well Founded Support Invariant: This invariant states that support trees are acyclic, i.e. that no 
node is a support node of itself. Specifically let n be any TMS node whose truth is either :true 
or :false and whose support is some clause c. The nodes other than n which appear in the. clause 
list of c will be called the immediate support nodes of n (a premise has no immediate support 
nodes). A node m will be called a support node of n if it is either an immediate support node of 
n or it is an immediate support node of some node which is a support node of n (thus the 
support nodes of n are those .nodes appearing in the support tree of /?). The premises which are 
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f\ support nodes of n will be called the support premises of n. 

Certainty Justification Invariants: These are two invariants which apply only to die TMS with 
the semi-automatic premise controller. To define the first certainty justification invariant let n be 
any premise, The truth of n must be the same as the default of // (which must not be nil) and the 
certainty of n must be the same as the default-certainty of n (which must also not be nil). In 
other words any premise must be a premise by virtue of the fact that it has a default value and 
the certainty of the premise is the default certainty. To define the second certainty, justification 
invariant let n be any node whose truth is either :true or :false and whose support is some clause 
c. The certainty of n must be die minimum of the certainties of all of ns immediate support 
nodes. This together with die well founded support invariant implies diat die certainty of n is 
die minimum of the certainties of all of die support premises of n. 

3.3.2 THE DEDUCTION INVARIANTS 

The TMS performs simple propositional deduction from clauses and the truth values which have been 

assigned to nodes. The deduction performed is not complete (i.e. there arc valid deductions which are not 

made). However die deduction processing is incremental and is guaranteed to terminate in linear time in the 

f*^s number of clauses in the system. The basic deduction invariant is that all deductions which can be made from 

a single clause and assignments of truth values to nodes have been made. 

Main Deduction Invariant: Let c be any clause whose psat is 1 (any clause such diat there is 
only one pair in its clause list which is not false). Let p be the pair in c which is not false and let 
n be the node which is the car of p. The main deduction invariant is that the truth of n is the 
same as the cdr of/?. If the truth of n was :unkno\vn then the clause c could be used to deduce 
that n must be assigned the truth value which is associated with it in p. The main deduction 
invariant says that all such deductions have been made. 

Default Value Invariant: This invariant applies only to the TMS with die semi-automatic 
premise controller. It ensures that any node which has a default truth value and which cannot 
be proven to have the opposite of its default value does in fact take on its default value. 
Specifically let n be any node whose default is not nil (i.e. any node with a default truth value). 
The default value invariant is that the truth of n must be either :true or :false and that the 
certainty of n must be at least as large as the default-cert of n (which must not be nil). 
Furthermore if the truth of n equals the default of n and the certainty of n equals the default-cert 
of n then die support of n must be nil (the node n must be a premise). 
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Deduction Certainty Invariant: This invariant applies only to the TMS with the semi-automatic 
premise controller. It says that each node is given the strongest (most certain) justification which 
can be found via the propositional deduction mechanisms used by the TMS. Specifically let c be 
any clause whose psat is 1, let p be the pair in c which is not false, and let n be the node which is 
die car of/?. The deduction certainty invariant is that the certainty of n is not smaller than the 
minimum of the certainties of the nodes in the false pairs of c. To better understand this 
invariant consider the relationship between the clause c and the node /?. By the main deduction 
invariant n must be assigned the truth value which is die cdr of p. However the support of n 
need not be die clause c. If c is not the support of n then c may provide an alternative method of 
deducing the truth value of // (the only problem would be if using c for the support of n would 
introduce a circular justification violating die well founded support invariant). If the certainty of 
n were less than die certainty which would result from using c as die support of n then c 
provides a "stronger" argument for the truth value assigned n and the support for n could be 
strengthened by setting it to c (it can be shown that such "strengthening" never introduces 
circularities). The deduction certainty invariant says diat all such possible strengthenings have 
been done. 

3.3.3 THE BACKTRACKING INVARIANT 

Any clause whose psat is is called a contradiction. Since each clause is interpreted as a tautological 
disjunction, if all pairs in a clause c are false dien die truth values which have been assigned to the nodes in 
those pairs are mutually contradictory. 

The backtracking invariant: This invariant is that for each contradictory clause c there is a list b 
on die queue ^backtracking-invariant* such that die car of b is die function which is the value of 
die variable *backtracker* and the cdr of b is a one element list containing c. Thus "running" b 
is equivalent to evaluating: (funcall *backtracker* c). 

*backtrackcr* variable 

The value of this variable is a backtracking function which is used to construct the item 
placed on the queue ^backtracking-invariant* when a contradiction arises. The default value of 
this variable is backtracker-default which is described below. 

*backtracking-invariant* variable 

The value of this variable is the queue associated with the backtracking invariant. 
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3.4. Major TMS Functions 

This section describes the TMS functions which might be of interest to the user. It also describes some 
parameters of the TMS which can be set by the user. 

add-clausc (clause-list) 

The clause-list must be a list of pairs each of which associates a TMS node with eidier :true 
or :false. This function creates a clause with the given clause list and ensures all of the TMS 
invariants by performing whatever deductions the clause allows and by queueing the 
backtracking of any resulting contradictions. 

node-add-clause (pos-nodes neg-nodes) 

The pos-nodes and neg-nodes arguments must both be lists of TMS nodes. This function 
first constructs a clause list by associating all the nodes in pos-nodes with :truc and all of the 
nodes in neg-nodes with rfalse. It then adds a clause with this clause list by calling add-clausc. 

implies (nodes node) 

/"""N A call to this function of the form (impiics nodes node) is equivalent to 

(node-add-clausc (list node) nodes). It adds a clause which represents the assertion that if all of 
the TMS nodes in the nodes argument are true then node should also be true. 

contradictory (nodes) 

A call to this function is equivalent to (node-add-clause nil nodes). It adds a clause which 
says that one of die nodes must be false. 

clause-cert (clause) 

This function is only defined in the TMS with the premise controller. This function takes a 
clause and returns the minimum certainty of the TMS nodes in the false pairs of that clause. The 
justification certainty invariant says that the certainty of a supported node equals the clause-cert 
of the support of that node. 

make-premise (node truth-value) 



/*> 



This function is only defined in the TMS without the premise control mechanism. This 
function forces the truth of the given node to be the given truth value which is required to be 
either :true or rfalse. If the given node was previously assigned the opposite value then 
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retraction is done before the new assignment is made. This function guarantees that all TMS 
invariants arc maintained. 

*min-cert*, *max-ccrt* variables 

These are variables which may be set by the user. All certainties must be between the 
values of *min-ccrt* and *max-ccrt* inclusive. The default values of *min-ccrt* and *max-cert* 
are 1 and 5 respectively. 

set-default (node value certainty) 

This function is defined only in the TMS with the premise control mechanism. This 
function sets the default of the given node to value and the default-ccrt of the given node to the 
given certainty. This function guarantees that all TMS invariants arc maintained by performing 
whatever truth assignments, retraction, deduction, and backtrack qucucing that is necessary. 
Thus if the truth of the given node was unknown before the call then the truth of die given node 
will be set to die given value (which must be :truc or :false). 

retract-premise (node) 

This function is only defined in the TMS without the premise controller. This function sets 
the truth of the given node to runknown and guarantees the maintenance of all TMS invariants. 
(Maintenance of the : nvariants requires a retraction phase in which all nodes which depended 
on the retracted node are retracted and a deduction phase in which all nodes which were 
retracted are checked to see if some alternative support is available. To avoid circular 
dependencies it is important that the retraction phase completes before the deduction phase 
begins. To achieve this there is an internal queue associated with the deduction invariants.) 

remove-default (node) 

This function is only defined in the TMS with the premise control mechanism. This 
function sets both the default and the default-ccrt of the given node to nil and maintains all TMS 
invariants. Thus the given node will not be a premise after this function exits. 

*view-node* variable 

This variable is bound to a function which when applied to a TMS node returns a "name" 
for that node. The default value for *view-node* is the function view-node-default which assumes 
that the assertion of the node is a term (described in the section on the equality system) and 
returns the expression which that term represents. 
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view-clause (clause) 

This function returns an "image" of the clause list of the clause in which each node has 
been replaced by the "name" of the node as given by die value of *vie\v-node*. 

nedc-why (node) 

This function generates an explanation for the truth value assigned the node. If the truth of 
die given node is :unknown then a simple statement to that effect is generated. If truth of die 
given node is :true or :falsc and its support is not nil dicn the generated explanation gives a 
numbered list of the immediately support nodes and their truths. The argument to node-why 
may be a number in which case an explanation is generated for die support node corresponding 
to that number in the previous explanation. If die argument is given dicn die explanation stack 
is "popped". The following scenario demonstrates die use of diis function. 

(setq *view-node* '(lambda (node) (assertion node))) 

(defun symbol-node (sym) 
(let ((n (make-tms-node))) 
(set sym n) 

(setf (assertion- n) sym) 
sym)) 

(symbol-node *p) 
(symbol-node 'q) 
(symbol-node *((:-> p q)|) 
(implies (list |(:-> p q)| p) q) 
(make-premise |(:-> p q)| ':true) 
(make-premise p *:true) 

(node-why q) 

"q is :true from" 

"1 | ( :-> p q) | is itrue" 

"2 p is :true" 

t 

(node-why 1) 

"|(:-> p q)| is :true as a premise" 

(node-why 0) 

"q is :true from" 

"1 | ( :-> p q) | is :true" 

"2 p is :true" 

t 

(node-why 2) 

"p is :true as a premise" 
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The node-why function allows the user to walk around the support tree of a node 
investigating various support paths. 

backtrackcr-default (clause) 

This is the default value of the variable *backtracker* which is used in constructing 
backtracking fonns to place on the queue ^backtracking-invariant* (see the section on the 
backtracking invariants). This function takes a clause and if the clause is not a contradiction it 
does nothing. Otherwise it first constructs a list of all the support premises of all the nodes in the 
clause (all of the premises underlying the contradiction). In the TMS with the semi-automatic 
premise controller this list is then filtered so that only those premises which have the least 
certainty remain. One premise from the candidate premises is then chooses for retraction. If 
there is only one candidate premise then this is the one chosen. If there is more than one 
candidate premise then the value of *prcmisc-seIector* is applied to the list of candidate 
premises and the premise returned is die one chosen for retraction. (The fact that the value of 
*premise-selector* may be called even in the TMS with the premise controller is die reason for 
calling this premise controller semi-automatic rather than automatic.) The premise chosen for 
retraction is retracted and then the negation of that premise is deduced from die other premises 
and the fact that the premises are mutually contradictory. 

*premise-selector* variable 

The value of this variable must be a function which takes a list of nodes and returns one of 
them. This function is only called on lists of nodes where die current truth values of the nodes in 
that list are mutually contradictory. The default value of *premise-selector* is 
premise-sclcctor-default which types the list of nodes at the terminal and asks the user to select 
one. 

premises (clause-list) 

This function returns a list of all the nodes which are premises which either appear directly 
in false pairs in the clause-list or are support premises of a node in a false pair in clause-list. This 
function can be applied to the clause list of a contradiction to get the set of premises underlying 
the contradiction or it can be applied the clause-list of the support of a node to get the set of 
premises supporting that node. 

reverse-truth (node contradiction) 

This function can be used to write backtracking functions. The given contradiction must 
be a clause whose psat is (a contradiction) and the given node must be a premise underlying 
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/**\ ' that contradiction. This function forces truth of node to be set to the opposite of the value it has 

when the function is called. All TMS invariants arc maintained. Note that in the TMS with the 
premise controller a call to reverse-truth normally results in the other nodes underlying the 
contradiction being the premises supporting the reversed value of the given node and therefore 
the certainty of the node ends up being the minimum of the certainty of these premises. 
However if the given node has a default strength which is greater than the minimum strength of 
the other premises underlying this contradiction, a problem arises. Specifically the default value 
invariant says that die certainty of a node with a default value can not be less than flic default 
certainty. If such a problematic reversal is attempted it simply will not "stick" and the system 
will end up in much the same state that it started in. 

nodc-try-to-show (node value &optional refutation-queues split-nodes (certainty *min-cert*)) 

This function uses a refutation mechanism to extend the deductive power of die TMS, In 
the TMS without die premise controller the given node must be a TMS node whose truth is 
lunknown. In the TMS with the premise controller either the truth of die given node must be 
runknown or the certainty of the node must be less than flic given certainty. This function 
attempts to prove from the premises already in die TMS that the given node must be assigned 
the given truth value. In die TMS with the premise controller this function attempts to prove 
. that the given node must be assigned the given value using only the premises of of certainty 
greater than or equal to the given certainty. Thus this function can be used to search for a 
stronger proof of a trvth value assignment which is already in force. 

The. function nodc-try-to-show works by assuming the negation of die thing to be proven 
and searching for a contradiction. It takes an optional list of refutation queues which are queues 
to be emptied after the negation has been assumed. The assumption of the negation may trigger 
demons which are placed on queues. Running diose demons may lead to the deduction of a 
contradiction based on the assumption which would otherwise not have been found. The 
function multi-fifo-empty is used to empty the queues once the assumption has been made. 

The function node-try-to-show also takes an optional list of split nodes. If split nodes are 
provided then an attempt is made to prove that all assignments of truth values to the split nodes 
imply the desired truth value and therefore that this value holds independent of the truth of the 
split nodes. This is done by actually assigning all possible combinations of truth values to the 
split nodes and for each such assignment using die refutation mechanism and the rqueues to try 
to show that the negation of desired truth value leads to a contradiction. 

The following scenario provides an example of the use of this function. The functions used 
in this scenario are defined elsewhere in this manual. For die following example it is important 
to note that if there is a constraint in the TMS which says that either p or q must be true, and p is 
made false, then q will be deduced to be true. This is important when p is used as split node. 
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^.^ (notice (:true (p ?x)) *some-queue* 

H (Iconst (:-> (p-?x) (r ?x)))) 

(notice (:true (q ?x)) *some-queue* 
(Iconst (:-> (q ?x) (r ?x)))) 

(assert *(:or (p a) (q a))) 

(why f (r a)) 

"I DON'T KNOW WHETHER OR NOT (R A) IS :TRUE" 

(node-try-to-show (virt-tms-node (term *(r a))) 
' : true 

(list *some-queue*) 
(list (virt-tms-node (term '(p a))))) 
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(why '(r a)) 

"(R A) IS :TRUE FROM:" 



"1 ( 
"2 ( 

"3 ( 



> (P A) (R A)) IS 

> (Q A) (R A)) IS 
OR (P A) (R A)) IS 



TRUE" 
TRUE" 
TRUE" 



3.5. TMS Noticers 

Each node has three noticer slots, truc-noticcrs, false-noticcrs, and changc-noticcrs, each of which 
contains a list of "noticers". A noticer is a cons cell whose car is a queue and whose cdr contains an item to be 
placed on that queue when the noticer "triggers". Under certain conditions all of the noticers in a given 
noticer slot will be triggered and the noticer slot will be set to nil. Thus a given noticer in a given slot will only 
be triggered once. True noticers (the cells in the true-noticers slot) are triggered whenever the node becomes 
true. False noticers are triggered whenever the node # becomes false and change noticers are triggered 
whenever any change is made either to the truth or the certainty of the node. 

It is often desirable to have a certain demon run whenever a node becomes true rather than just the first 
time that node becomes true. There is a straightforward way of doing this which is exemplified by the 
following scenario. When the below function notice-problem is applied to a queue and a node it first checks to 
sec if the node is true and if so it applies a special handler to that node. Independent of whether or not the 
node is true however it places a true noticer on the node using the given queue. This noticer is such that if the 
node is ever set to true in the future then this function will be called again with the same arguments. 

(defun notice-problem (queue problem-node) 
(if (eq ':true (truth problem-node)) 

(problem-handler problem-node)) 
(push (cons queue (list 'notice-problem queue problem-node)) 
(true-noticers problem-node))) 

(notice-problem *some-queue* n) 
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^ 4. THE EQUALITY SYSTEM 

The equality system is a collection of utilities for handling the substitution of equals for equals. The 
description of the equality system given here is divided into three parts. The first describes terms and the 
interning of terms. Terms are analogous to a LISP atoms in that they are interned so that one can guarantee 
that there are no two distinct terms with the same print name. Unlike LISP atoms however terms can be 
either atomic or can contain subtcrms which can be substituted for in the equality system. The second part of 
this section describes the equality and equivalence class data structures and the equality invariants which 
specify die substitution computations. The final part of this section describes simplification utilities which 
allow the user to define a somewhat arbitrary simplicity order on terms and then computes the simplest term 
which can be equated with any given term via the substitution of equals for equals. 

4.1. Terms and Interning 

Terms are defined as follows: 

(defstruct (term (:type : named-array) ) 
(term-hash (hash-count)) 
subterms 
parents 
eqs 

next-canonical 
/***N eq-next-canonical-eqs 

class-data 
term- tms-node 
user- referenced? 
(term-pl ist (neons nil)) 
(term-extension (funcal 1 *make-term-extensi on*)) ) 

The various slots of this data structure are described below. 

term-hash This is an integer which is unique to this term. This integer is used as a hash value 
for the term. 

subterms This slot holds two basically different kinds of information depending on the kind of 
term involved. If the term is a composite term then this slot holds a list of the subterms of the 
term (a list of term data structures). For example a term whose print name is (f a b) would have 
subterms whose print names are f, a, and b respectively. If the term is "atomic" then it has no 
subterms and the subterms slot contains the print name of the term. There are three different 
kinds of atomic terms. First of all there are symbols whose subterms slot is simply a LISP 
symbol. Second there are numbers whose subterm slot is a LISP number. Finally there are 
quotations whose subterms slot contains a LISP expression whose car is the symbol quote. 
Numbers and quotations are self-referential terms. This means that these terms are interpreted 
f^' as denoting themselves. Specifically the term whose print name is the number 1 is taken to 
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/-^ denote the number 1 and the term whose print name is the expression (quote (fa)) is taken to 

denote the expression (fa). Self referential terms play an important role in the equality 
invariants. 

parents This slot contains a list of all those terms which contain this term as an immediate 
subterm (i.e. all those terms which contain this term in their sulrtcrms slot). This is used in the 
equality algorithms described in the next part of this section. 

eqs This is a list of all the equality data structures which equate this term with some other term. 
This slot is maintained by the function makc-eq described elsewhere. 

next-canonical This slot is either nil or contains a "more canonical" term. The function e 
described below takes a term t and returns its "canoni'calization" which is t if the next-canonical 
of t is nil and otherwise it is the canonicalization of the next-canonical of t. Two terms are 
equivalent just in case they have the same canonicalization. 

eq-ncxt-canonical-cqs The cq-next-canonical of a term t is not nil just in case the next-canonical 
of t is not nil in which case the eq-next-canonical-eqs of t contains a list of equality data 
structures which together imply that t is equal to the next-canonical oft. 
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class-data The class-data slot of a term t is not nil whenever there is some term s whose 
next-canonical is t. If die class-data of a term t is not nil then it is a class-data data structure 
which describes die set of terms whose next-canonical is t. The class-data data structure is 
described in section 3.2. 

term-tms-node This slot is eidier nil or contains a TMS node representing this term. If a,TMS 
node is present then the term represents an assertion. The function virt-tms-node described 
below takes a term and always returns a TMS node representing that term. For the equality 
invariants to be maintained it is important that all TMS nodes representing terms be created via 
virt-tms-node. 

user-referenced? This slot is a flag which is non-nil just in case this term has been returned as a 
value of the function term or die function term-hashcons. This is needed because the equality 
system creates internal terms via the substitution of equals for equals and it is not desirable to 
run demons on these terms. Specifically the value of the variable *new-term* (described 
elsewhere) is only applied to terms which are returned from term or term-hashcons. 

term-plist This slot is perfectly analogous to the nodc-plist slot 

term-extension This is perfectly analogous to the node-extension slot of TMS nodes. 
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^■•N The following functions and variables arc relevant to terms and interning. 

virt-tms-nodc (term) 

This function returns a TMS node that has been associated with the term. In order to 
maintain certain TMS-Equality interface invariants it is important that this be the only way in 
which the tcrm-tms-node slot of terms is set 

atomic? (term) 

This predicate is true of a term just in case the term is a symbol, a number, or a quotation. 
self-referential? (term) 

This predicate is true of a term just in case the term is a number or a quotation. 

term-tree (term) 

This function returns the print name of the term. Curried functions are treated specially 
(the print form is uncurricd) as is described in the section on curried functions. 

term (expression) 

This is the basic function for interning expressions as tci.ns. The expression argument can 
either be a number, a symbol, a term, or an arbitrary expression built out of numbers symbols 
and terms. If the expression is a term then the expression is simply returned. The expression is 
said to be atomic if it is a number or a symbol or die car of the expression is the symbol quote. If 
the expression is not atomic then this function first recursively computes the list of subterms 
which is the value of (mapcar 'term expression). It then returns the result of applying 
term-hashcons (described below) to this list of subterms. If the expression is atomic then if there 
is already a term whose print name is the expression then that term is returned. If there is not 
already such a term then one is created and returned. The value of the variable *new-term* is 
applied to all terms created in this way. This function maintains all of the equality invariants 
described later. 

term-hashcons (subterms) 
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, This function takes a list of subterms and returns a term corresponding to that list of 

} 'subterms. This function first applies the value of the variable *intern~carionicalize* (described 

below) to the list of subterms. The value of *intern-canonicalize* must be a function which 
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/^■N returns either a term or a list of subterms. If a term is returned then that term is simply returned 

from term-hashcons. If a list of subterms is returned then this function looks for an already 
existing term which has tills list of subterms in its subterms slot (a hash table is used here for 
efficiency). If such a term exists it is returned. If no such term exists one is created and returned. 
The value of die variable *ncwtcrm* is applied to all terms created in this way. This function 
maintains all equality invariants. 

*intern-canonicalizc* variable 

This variable must be bound to a function which takes a list of terms and returns either a 
term or a list of terms. This is used to map different expressions for the same thing into identical 
term structures directly in the interning process. For example if a function f is known a-priori to 
be an a commutative function then die expression (fa b) must denote die same tiling as the 
expression (f b a). The default value of *intern-canonica!izc* is intcrn-canonicalize-default which 
is described below. 

intcrn-canonicalize-default (subterms) 

Terms representing functions of two arguments can be marked as being either associative, 
f^^ s commutative, or both (see the -macros associative? and commutative? defined below). For 

example the term whose print name is + is marked as both associative and commutative. The 
function intcrn-canonicalize-default takes a list "of subterms the first of which is a term 
representing an operator (function or predicate). If the operator term is not marked as being 
either associative or commutative then the list of subterms is simply returned by 
intcrn-canonicalize-default. If the operator term is marked as associative then the argument 
subterms are searched for an application of that same operator and if one is found the 
arguments in that application are promoted to top level arguments. For example if f is marked as 
an associative operator then (fa (f b e)) is converted to (f a b c). Since f is binary (only binary 
functions should be marked as associative or commutative) the term (fa b c) is interpreted by 
convention as (f (f a b) c). After the promotion of "internal" arguments for associative operators 
this function checks to see if the operator is marked as commutative. If so then the arguments 
are sorted by their term-hash slots. Finally the resulting list of subterms (including the operator 
term) is returned from intern-canonicalize-default. 
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/""s associative? (op-term) 

This is a macro which expands as follows: 

(associative? op-term) ■■==> (get (term-plist op-term) 'associative?) 

To mark an operator term as associative one simply evaluates: 

(sctf (associative? op-term) t) 

commutative? (op-term) 

This macro is just like associative?. 

*ncw-tcrin* variable 

The value of this variable must be a function which is applied exactly once to every term 
which is ever returned from term or tcrm-hashcons. The default value of this variable is 
new-term-default. For the symbols =, ->, and, or, etc. to be given the proper interpretations in 
the top level RUP environment the function new-term-default should be called on all terms 
returned from term-hashcons. Thus any function which the user assigns to *ncw-term should 
call new-term-default on its argument if the standard interpretation of the above symbols is 
desired. 

new-term-default (new-term) 

This is the default value of the variable *ncw-term*. The function new-term-default queues 
applications of hashcons noticers. Hashcons noticers are functions which are associated with an 
operator term and a queue. When new-term-default is applied to a term u it checks the first 
subterm of u (u's operator) to see if there are any hashcons noticers associated with that operator 
(if the given new-term is atomic then new-term-default does nothing). For each such noticer an 
application of that noticer to u is placed on the queue associated with the noticer. Noticers are 
stored on the hashcons-noticer property of operator terms. Whenever new-term-default is 
applied to a non-atomic term u the term u is added to the applications property of the operator 
ofu. 
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add-hashcons-noticcr (op-term noticer queue) 

This function associates the given noticer (which must be a function of one argument) with 
the given op-term and the given queue. This function queues applications of the given noticer to 
all currently existing applications of the given op-term. 

hi shcons-noticers (op-term) 

This is a macro which expands as follows; 

(hashcons-noticers op-term) = => (get (lerm-plist op-term) 'hashcons-noticers) 

applications 

This is a macro which expands as follows: 

(applications op-term) = => (get (tcrm-plist op-tcrm) 'applications) 

4.2. Equalities, Equivalence Classes, and the Equality Invariants 

The equality system maintains a congruence relation on terms. The following function can be used to 
determine whether or not two terms arc congruent under this relation. 

e(term) 

This function is defined as follows: 

(defun e (term) 

(if (next-canonical term) 

(e (next-canonical term)) 
term)) 

Two terms are congruent just in case they have the same image under e. 

The following defines one of the basic data types in the equality system. 

(defstruct (equality (:type tnamed-array)) 
terml 
term2 

dependents 
eq-node) 

The slots of the equality data structure are described below. 

terml, term2 These slots contain die terms equated by the equality. 
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^*N dependents This slot contains the list of all terms which contain the equality in their 

eq-ncxt-canonical-eqs slot. 

cq-node This slot holds the tins node which represents the equality. 

The equality system is driven by changes in the truth values of the TMS nodes associated with equalities. 
Therefore die only interesting top level functions for the equality system are for querying the data structures 
involved. 

make-eq (terml term2 tms-node) 

This function should be used uniformly instead of the make-equality macro constructed by 
defstruct. This function creates an equality data structure and sets the terml, tcrm2, and cq-node 
slots of that structure to the arguments provided. It also updates the eqs slot of both terms. 
Finally it places a change noticcr on the given tms-node which will arc needed to ensure the 
equality invariants. 

true-eq? (equality) 

This macro expands as follows: 

(true-eq? equality) ==> (cq ': true (truth (eq-nodc equality))) 

cquated-support (terml tenn2) 

If terml and tcrm2 are not in the same equivalence class then this function returns nil. If 
terml and term2 are in the same equivalence class then this function returns a list of TMS nodes 
which represent equalities implying the equivalence of terml and term2. 

same-image? (terml term2) 

This predicate is non-nil just in case terml and term2 have the same number of subterms 
and those subterms are equivalent in pairs. 

class-members (term) 

This function returns a list of all terms which are congruent to the given term (all interned 
terms that is). 
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equivalents (term) 

This function returns a list of terms in the equivalence class of term such that no two terms 
in that class have the same image (i.e. their subterms are equivalent in pairs). Thus the list of 
terms returned is the set of "independent" terms equivalent to term. 

A term u is said to point to a term t just in case eidier t is the next-canonical of u or in case die 
next-canonical of u points to t. A class-data data structure c is always contained ia the class-data slot of 
exactly one term t called the owner of c. If c is die class-data of t then c describes die set of terms which point 
to t. This data structure is defined as follows: 

(defstruct (class-data) 
members 

member-referents 
(size 1) 
(class-ptist (neons nil))) 

The slots of these structures have die following functions: 

members The members slot of c is a list of terms whose next-canonical is the owning term t of c. 
Note that' this is a subset of all die terms which point to t. 

membcr-refercnts The member-referents slot of c contains a list of all self referential terms 
which point to the owner of c. 

size The size of c is one plus the number of terms which point to die owner of c. ' 

class-plist This slot is analogous to the node-plist slot of TMS nodes and the term-plist slot of 
terms. 

The following are the Equality Invariants. These invariants are associated with the queue 
*equality-invariants* and are only guaranteed in environments in which this queue has been emptied. 

Equality Justification Invariant: For any term t with a non-null next-canonical slot the set of 
equalities in die eq-next-canonical-ecjs slot of t are all true equalities (the truth of their eq-nodes 
is :true) and this set of equalities implies that the u is equal to die next-canonical of u. 

Congruence Deduction Invariant: For any term t let subterm-image(t) be die term which results 
from replacing each subterm u of t by e(u) (if t is atomic then subterm-image(t) is just "t). The 
congruence invariant is that for every term t, subterm-image(t) is an interned term which is in 
the equivalence class of t. This invariant implies that any two terms whose subterms are 
equivalent in pairs are themselves equivalent. It also implies that any two terms which can be 
shown equivalent via the substitution of equals for equals are in fact equivalent. For efficiency 
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^^ reasons this invariant is not maintained on terms which are applications of =, or, ->, and, not, 

and iff. Instead the TMS can be used in conjunction with refutation to show any derivable 
logical equivalences between these terms. 

True Equality Deduction Invariant: The terms of any true equality are both in the same 
equivalence class. 

Derived Equality Deduction Invariant: Let e be any equality such that the terms of e are both in 
the same equivalence class. There is a clause in the TMS which states that some set of true 
equalities imply e. Thus if e is :falsc there is a contradiction in the TMS, and if e is not :false it 
must be :truc (as opposed to unknown). 

Assertional Term Invariant: Let t be any asscrtional term (a term with a tcrm-tms-node). If t has 
a next-canonical then the next-canonical of t is also an asscrtional term and there are clauses in 
the TMS which state that the eq-ncxt-canonical-cqs of t imply the equivalence of the 
term-tms-node oft and the term-tms- node of the next-canonical oft. This invariant ensures that 
any two assertional terms which are in the same equivalence class arc constrained to be logically 
equivalent. 

/*""s *equate-state* variable 

This variable is set to a new value each time the congaience relation on terms is changed. 
This is useful for memoi/Jug computations which depend on the congruence relations. A 
memoized value is valid as long as *equate-state* has the same value that it had when the 
memoization was done. 

4.3. Simplification 

The functions described here allow the user to define a simplicity order on terms and then efficiently 
simplify terms. Specifically let u be some term. The functions described compute a term which is at least as 
simple under the user defined order as any term which can be equated with u via the substitution of equals for 
equals based on the premise equalities. For example suppose one has the function symbol + which is to be 
interpreted as standard addition over the integers and consider a term of the fonn (4- (4- x y) z). If this term 
could with a term composed entirely of numerals and the function symbol -f then that term could be 
"evaluated" to yield a numeral equivalent to the original term. The problem of finding an expression for a 
given term in terms of some subset of "allowed" terms can be solved by defining a simplicity order in which 
terms containing only allowed symbols are simpler than terms containing symbols which are not allowed. 
/■^s A simplicity order is defined by setting the following three variables to appropriate functions. 
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*atomic-level* variable bound to function with argument list: (atomic-term) 

This variable must be bound to a function which takes an atomic term and returns a 
"lever 1 . Levels can be any data structures so long as they arc consistent with die values of the 
next two variables. The default value of this function is atomic-level-default described below. 
The default levels are integers. 

*suhterm-level* variable bound to function with argument list: (subterm-levels) 

This variable must be bound to a function which takes a list of levels and returns a level 
which is the level of any term whose subterms have the corresponding levels. The default value 
of this variable is subtcrm-lcvcl-default which simply computes die maximum of the subtcrm 
levels. 

♦smaller?* (levell level2) 

This variable must be bound to a predicate which takes two levels and returns a non-nil 
value just in case the first level is "smaller" (i.e. simpler) than the second. The default value of 
this function is the lisp less dian function <. 

The termination and correctness of the simplification procedures depend on some assumptions about 
the simplicity order. These assumptions are as follows: 

Well Foundedness Assumption: There can be no infinitely decreasing chains of levels. 

Monotonicity Assumption: Let s and t be any two terms with the same number of subterms 
such that s is simpler than t (has a smaller level). There must be some pair of corresponding 
subterms s' and t' of s and t respectively such that s' is simpler that t\ In other words the 
function bound to *subterm-level must be non-decreasing in each sublevel argument. 

Subterm Simplicity Assumption: No term can be simpler than a term it contains as a subterm. 

Pseudo Total Order Assumption Let lj and 1 2 be any two levels such that 1 j is less than U. No 
third level 1 3 can be unrelated to both lj_ and 1 2 (i.e. I3 must be either smaller or greater than 
either lj or 1 2 ). 

new-simplifieation-state 

This function of no arguments must be called each time the user changes the simplification 
^""^ order. 
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atomic-levcl-dcfault (atomic-term) 

This function is the default value of *atomic-lcvel*. It takes an atomic term and returns a 
non-negative integer. If the term has an atomic-level property then the value of this property is 
returned. Otherwise the number returned is for self referential terms and 1000 for all other 
atomic terms. 

atomiclevcl-prop (term) 

Tliis is a macro with the following expansion property: 

(atomic-levcl-prop term) = => (get (term-plist term) 'atomic-level) 

Thus to set the atomic level of a term one simply evaluates: 

(setf (atomic-level-prop term) n) 

However whenever this is done the function ncw-simplification-state should be called. 

sbound (term) 

This function takes a term and returns an expression which is the print name of a term (not 
necessarily an interned term) which is at least as simple as any term which can be equated with 
the argument via the substitution of equals for equals using the premise equalities'. 
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_ 5. THE TOP LEVEL RUP ENVIRONMENT 

The top level RUP environment provides several convenient user level functions such as assert, retract, 
and why each of which takes expressions and converts them to asscrtional terms. Demons which trigger on the 
creation of terms are used to provide automatic interpretations for the logical operators, =, :->, :and, :or, :not, 
and riff. There is also a macro which converts logical constraints represented as a sentence of propositional 
logic and converts it to an equivalent set of applications of add-clause. There are also mechanisms for saving 
partial RUP environments so that one can return to a known state during debugging. 

5.1. Top Level Functions 

assert (cxp &optional (certainty *max-cert*)) 

This function first computes die term whose print name is exp and then calls virt-tms-node 
to get a TMS node associated with this term. If die TMS without the premise controller is being 
used then the function make-premise is called on die TMS node and the truth value :true. If the 
TMS with the premise controller is being used then the function set-default is called on the 
node, the truth value :true and the the certainty argument to assert (note that the default 
certainty is *max-ccrt*). Finally this function applies multi-fifo-empty to the value of 
f\ *basic-queues*. 

retract (exp) 

This function first finds the TMS node associated with the term whose print name is exp. It 
then either calls retract-premise or remove-default on that node depending on which TMS is 
being used. This function applies multi-fifo-empty to die value of *basic-queues*. 

= -noticer (eq-term) noticer for = on queue *equality-invariants* 

This function is an intern noticer for applications of =. Since eq-term is an application of 
= die second and third subterms of eq-term are the equated terms. The function virt-tms-node 
is called to get a TMS node representing eq-term and the function make-equality is applied to 
the equated terms and the TMS node. 

->noticer (implication-term) noticer for :-> on queue *rup-top-level* 

This function is an intern noticer for applications of :->. This function adds clauses to the 
TMS which ensure that the symbol :-> is interpreted as logical implication. For each 
implication of the form (:-> p q) the following clauses are added: (each of the below clauses is 
1 written as a list of disjuncts. 
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(((:-> p q) . rfalse) (p . rfalse) (q . :true)) 
((p . :true) ((:-> p q) . rtrus)) 
((q • rfalse) ((:-> p q) . :true)) 

These clauses relate three TMS nodes: the node representing an implication (:->pq), the 
node representing die antecedent p, and the node representing the consequent q. The best way 
to think about these clauses is that they force die TMS to make all possible deductions 
concerning these diree nodes. For example if the implication and the antecedent are true then 
the consequent will be deduced via die first of the above clauses, If the antecedent is true and 
die consequent is false then that same clause is used to deduce that the implication must be 
false. If die antecedent is false dtcn the second clause can be used to deduce that the 
implication, and so on. 

not-noticer (negation-term) noticer for not on queue *rup-top-lcvd* 

This function is an intern noticer for applications of not. For each negation of the form 
(:not p) die following clauses are added: 

(((:not p) . :true) (p . rfalse)) 
(((rnot p) . rfalse) (p . rtrue)) 

or-noticer (disjunction-term) noticer for or on queue *rup-top-Icvel* 

This function is an intern noticer for applications of or. A disjunction term can have an 
arbitrary number of disjuncts. For each disjunction of die form (:or p q ...) the following clauses 
are added: 

(((:or p q ...) . rfalse) (p . rtrue) (q . rtrue) ...) 
(((:or p q . . .) . rtrue) (p . rfalse)) 
(((:or p q ...) . rtrue) (q . rfalse)) 



and-noticer (conjunction-term) noticer for and on queue *rup-top-level* 

For each conjunction of the form (:and p q ...) die following clauses are added: 

(((rand p q ...) . rtrue) (p . rfalse) (q . rfalse) ...) 
(((rand p q ...) . rfalse) (p . rtrue)) 
(({rand p q ...) . rfalse) (q . rtrue)) 
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iffnoticer (log-eq-term) noticcr for iff on queue *rup-top-levcl* 

This function is an intern noticcr for applications of iff. This function adds clauses to the 
TMS which constrain the truth of die TMS node associated with die logical equivalence term to 
be the appropriate function of the truth values of the TMS nodes associated with the 
equivalenced terms. For each logical equivalence of die form (riff p q) the following clauses are 
added: 

(((:iff p q) . :false) (p . :fa!se) (q . :true)) 

(((:iff p q) . :false) (p . :true) (q . :false)) 

(((:iff p q) . :true) (p . :true) (q . :true)) 

(((:iff p q) . :true) (p . :false) (q . :fa!se)) 

why(exp) 

If exp is a number dien this function simply calls node-why on diat number. Otherwise this 
function gets die TMS node associated with the term whose print name is exp, dien applies 
multi-fifo-cmpty to "basic-queues; dien calls node-why on that node. The following is a typical 
top level RUP scenario. 

(assert *(:-> p q)) 

(assert ' ( :-> q r)) 

(assert 'p) 

(why *r) 

f, R IS :TRUE FROM:" 

"1 Q IS :TRUE" 

"2 (:-> Q R) IS :TRUE" 

(why 1) 

"0 IS :TRUE FROM:" 

"1 P IS :TRUE" 

"2 (:-> P Q) IS :TRUE" 

(why 1) 

"P IS :TRUE AS A PREMISE" 

(why 0) 

"Q IS :TRUE FROM:" 

"1 P IS :TRUE" 

"2 (:-> P 0) IS :TRUE" 

(why 0) 

"R IS :TRUE FROM:" 

"1 IS :TRUE H 

"2 (:-> R) IS :TRUE" 

(why 2) 

"(:-> Q R) IS :TRUE AS A PREMISE" 
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/"n try-to-show (exp &optional rqucucs snodcs (certainty *min-cert*)) 

A call to this function is equivalent to: 

(nodc-try-to-show (virt-tms node (term exp)) *:truc rqucucs snodes certainty) 

The following scenario uses this function. 

(assert *( : -> p r)) 

(assert *( :-> q r)) 

(assert '( :or p q)) 

(why 'r) 

"I DON'T KNOW WHETHER OR NOT R IS TRUE" 

(try-to-show *r) 
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what-is(exp) 

This function is defined as follows: 



(defun what-is (exp) 
(sbound (term exp))) 



why- is (exp) 

This function is defined as follows: 



(defun why-is (exp) 

(why '(= ,exp t (sbound (term exp))))) 



termq (exp) 



f**^: 



This macro is very much like backquote in LISP. If exp contains no "special" symbols 
then this macro takes an expression and macroexpand to a form which will evaluate to the term 
whose print name is that expression. Special symbols are those which start with either "?" or T\ 
It is assumed that symbols starting with "?" will be bound to terms at eval time and that symbols 
starting with M !" will be bound to lists of terms. The following are examples of macroexpansions 
of this form: 
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f\ (termq (f a)) ==> (term '(f 'a)) 

(termq (f ?a)) ==> (term-hashcons (list (term *f) ?a)) 
(termq (g . largs)) *=> (term-hashcons (cons (term *g) largs)) 

Iconst (exp) 

This is a very useful macro fcr adding clauses in the TMS. This macro takes a logical 
expression and macroexpands to a set of add-clauscs representing that expression. This macro 
treats symbols starting with "?" or "! ' in much the same as does termq. The following is a list of 
sample inacroexpansions: 

(Iconst (:-> (:and pi p2 p3) r)) 

= =*>(add-clause (list (cons (virt-tms-node (term *pl)) *:false) 

(cons (virt-tms-node (term *p2)) *:false) 

(cons (virt-tms-node (term 'p3)) * :false) 

(cons (virt-tms-node (term *r)) ' :true))) 

(Iconst (:-> (:and (forall (x) (:-> (p x) (q x))) 
(P ?a)) 
(q ?a))) 

»=*>(add-clause (list (cons (virt-tms-node 

(term '(forall (x) (:-> (p x) (q x))))) 
*:false) 
/*^\ (cons (virt-tms-node 

(term-hashcons (list (term *p) ?a))) 
* :fal se) 
(cons (virt-tms-node 

(term-hashcons (list (term 'q) ?a))) 
f :true))) 

(Iconst ( :iff p q)) 

Bss >(progn 

• (add-clause (list (cons (virt-tms-node (term 'p)) ';false) 

(cons (virt-tms-node (term *q)) *:true))) 

(add-clause (list (cons (virt-tms-node (term *p)) »:true) 

(cons (virt-tms-node (term *q)) ':false)))) 

Note that (Iconst (:-> p q)) is different from (assert (:-> p q)) in that the former does not 
create a term or a tms node representing (:-> p q) but instead simply installs a clause in the TMS, 
while the latter creates a term and a TMS node representing (:-> p q) and then asserts that that 
TMS node is true. 

assertq, retractq, whyq, try-to-showq, what-isq, why-isq 

These macros are just like assert, retract, etc. except that they use termq to quote there 
arguments. Thus (assertq p) is just like (assert (termq p)). 
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^**s 5.2. Initialization 

When trying to debug code which interacts with the utilities in RUP it is easy to become confused about 
the current state of die RUP environment. It would be nice to be able to save the state of the RUP 
environment at some point and be able to return to that state at some latter point. This section describes some 
features of RUP which approximate this behavior. 

tcrm-initO 

This function of no arguments flushes all existing terms so that any term which is 
subsequently returned from either the function term or the function tenn-hashcons is a 
completely new data structure. This has serious ramifications for the RUP environment. It 
means that there are no longer any noticers attached to any accessible operator terms (since 
those terms are new structures and have no noticers attached). It means that the simplification 
properties attached to terms have been effectively flushed. It means that the commutative and 
associative properties of operator terms have been flushed. 

*pcrm-init-forms* variable 

/■■*\ This variable is bound to a list of LISP expressions which get evaluated when RUP is 

initialized and thus the forms on this list determine the state of RUP which results from an 
initialization. This is the mechanism provided by RUP for "saving" or "defining" RUP 
environments. The default value of *perm-in it-forms* is a list of forms which restore the default 
RUP environment. The forms in *perm-init-forms get evaluated in the reverse of the order in 
which they appear. Thus the last tiling pushed onto die list is the last thing evaluated during 
initialization. It is important that any forms which change the intern canonicalization process 
are evaluated before the interning of any term affected by that change. For example it is 
important that the term for = be marked as commutative before any applications of that term 
are interned. 

*temp-init-forms* variable 

This variable is just like *perm-init-forms* except that its default value is nil. The intended 
use of this variable is described in the below documentation of the functions fix-temps and 
rup-init. 
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j ^*" s *k fJx-tcmpsQ 

This function of no arguments is defined as follows: 

(defun fix-temps () 

(setq *perm-init-forms* (append *temp-ini t-forms* *perm-ini t-f orms*) ) 
(setq *temp-init-forms* nil)) 

The basic philosophy behind this function is that as one develops a RUP environment one 
can push forms onto *temp-init-forms* which will to some extent recreate the environment 
being developed. Then when one wishes to store that environment so that it will be 
reconstructed after an initialization one calls the function fix-temps. 

rup-init (&optional save- flag) 

This function calls tcrm-init, and evaluates the forms in *pcrm-init-forms* in the reverse of 
the order in which they appear on the list (i.e. the forms are evaluated in the order in which they 
were placed on die list). Finally if the savc-flag argument is not nil it evaluates die forms on 
*tcmp-init-forms* in reverse order. If the save flag is nil dicn it sets *temp-init- forms* to nil. 
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f-s 6. THE NOTICE MACRO 

This section describes a macro which is used to define demons which trigger on certain events in the 
R UP environment, 

notice ((event pattern) queue &rcst body-forms) 

The notice macro defines demons which are queued when certain events take place in the 
RUP environment. The event argument must be one of several meaningful keywords and the 
pattern argument is an expression which may contain "variables" which arc symbols starting 
with either "? M or "!". The queue argument must be a form which evaluates to a queue and the 
body-forms can be any lisp expressions to be evaluated when the demon runs (i.e. they are die 
body of the demon). The details of die notice macro are best described through examples. 
Initially only die keyword :intcrn will be considered. 

6.1. Creating Intern Noticers 

When an application of notice is macroexpanded two function definitions arc created by side effect and 
the notice form macrocxpands'to an application of add-hashcons-noticcr. The function definitions must be 
^^ explicitly evaluated using die macro include-end-forms. Consider the following example: 

(notice (:intern (p ?a)) *user-queue* 
(Iconst (-> (p ?a) (q ?a)))) 

(include-end-forms) 
This macroexpands to: 

(progn (add-hashcons-notlcer (term *p) ' |(P ?A)-UNIFIER| *user-queue*) 

(push '(add-hashcons-noticer (term *p) ' |(P ?A)-UNIFIER| *user-queue*) 
* temp- i nit-forms*)) 

(progn 'compile 

(defun |(P ?A)-UNIFIER| (term) 

(let ((args (cdr (subterms term)))) 
(if args 
(let ((?a (car args))) 
(if (null (cdr args)) 
(|(P ?A)-B0DY| ?a)))))) 

(defun |(P ?A)-B0DY| (?a) 

(add-clause (list (cons (virt-tms-node 

(term-hashcons (list (term *p) ?a))) 
' :false) 
(cons (virt-tms-node 

(term-hashcons (list (term *q) ?a))) 
•:true))))) 
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/""N In *e above expansion the notice form macrocxpands into a progn which both installs a symbol as a 

noticer and pushes a form onto *tcmp-init-forms* (*temp-init-forms* can be used to re-create a RUP 
environment during initialization as is described elsewhere). Because the demons created by notice are 
implemented as intern noticers associated with operator terms it is important that the car of the pattern not 
contain variables to be bound during the triggering process. The form (include-cnd-forms) macrocxpands into 
a list of function definitions. The first function defined in the above example takes the term and performs the 
unification of the term and the pattern. The second function takes the bindings derived from this unification 
ard executes flic body of the noticer. The need for two functions (as opposed to a single function which does 
both unification and executes the body) involves keywords other than :intcrn. The need for include-cnd-forms 
should be clear from the following more complex example involving embedded demons. 

(notice (:intern (f unction-f rom ?f ?domain ?range)) *user-queue* 
(notice (:intern (?f ?x)) *user-queue* 

(lconst (-> (and (f unction-f rom 7f ?domain ?range) 
(Tdomain ?x)) 
(?range (?f ?x)))))) 

( incl ude-end- forms) 
The above macrocxpands to: 

(progn (add-hashcons-noticer (term 'function-f rom) 

' I(FUNCTI0N-FR0M ?F TDOMAIN TRANGE)-UNIFIER| 
/**"*% *user-queue*) 

" (push f (add-hashcons-nuticer (term ' function-f rom) 

'|(FUNCTION-FROM ? F TDOMAIN TRANGE) -UNIFIER | 
*user-queue*) 
*temp-init-f orms*) ) 

(progn 'compile 
(defun |(FUNCTI0N-FR0M TF. TDOMAIN ?RANGE)-UNIFIER| (term) 
(let ((args (cdr (subterms term)))) 

(if args 
. (let ((?f (car args))) 
(if (cdr args) 

(let ((Tdomain (cadr args))) 
(if (eddr args) 

(let ((Trange (caddr args))) 
(if (null (edddr args)) 
(|(FUNCTION-FROM ?F TDOMAIN ?RANGE)-BODY| 
Tf ?domain Trange)))))))))) 

(defun |(FUNCTI0N-FR0M TF TDOMAIN TRANGE)-BODY| (Tf Tdomain Trange) 
(add-hashcons-noticer Tf 

* ( lambda (term) 

(|(?F TX)-UNIFIER| term \Tf ', Tdomain \?range)) 
*user-queue*)) 

(defun |(?F TX)-UNIFIER| (term Tf Tdomain Trange) 
(let ((args (cdr (subterms term)))) 
(if args 
(let ((Tx (car args))) 

(if (null (cdr args)) 

(|(?F TX)-B0DY| Tx Tf Tdomain Trange)))))) 
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f m \ (defun |(?F ?X)-B0DY| (?x ?f ?domain ?range) 

(add-clause (list (cons (virt-tms-node 
( term-hashcons 
(list (tern ' function-f rom) 
?f ?domain ?range))) 
*:false) 
(cons (virt-tms-node 

(term-hashcons (list ?domain ?x))) 
1 : false) 
(cons (virt-tms-node 
(term-hashcons 
(list ?range 

(term-h.ishcons (list ?f ?x))))) 
-true))))) 

The embedding of the notice macro in the above example is very similar to embedding of PLANNER or 
AMORD demons. The variables in the inner demon inherit their bindings from the outer demon. In any use 
of notice the car of the pattern must not contain variables to be bound during triggering. However the car of 
the pattern may contain variables which are bound outside die notice construct. Note that the internal notice 
form macroexpands to an application of add-hashcons-noticer involving the function |(?F?X)| (die variable 
*tcnip-init-forms* is not effected by die inner noticcr). Without the macro include-cnd-forms it would be very 
hard for the internal notice form to define functions in such a way that they could be compiled. 

6.2. Naming Conventions for Noticer Functions 

/■"■n Two functions are defined by side effect each time an application of notice is macrocxpanded. Each 

function is given a name which is a symbol interned in the RUP package (or simply an interned symbol in 
MACLISP). The names of the functions are derived from die pattern in the notice form (as shown in the 
above examples). However special care has been taken to allow for more than one demon with die same 
pattern. For example the following 

(notice (:intern (p ?x)) ...) 

(notice (:intern (p ?x)) ,..) 

(notice (:intern (p ?x)) ...) 
( include-end-forms) 

macroexpandto: 

(progn (add-hashcons-noticer (term *p) ' |(P ?X)-UNIFIER| ...) 
(push '(add-hashcons-noticer ...) 
*temp-init-forms*)) 

(progn (add-hashcons-noticer (term f p) '|(P ?X)-2-UNIFIER| ...) 
(push '(add-hashcons-noticer ...) 
* temp- i nit-forms*)) 

(progn (add-hashcons-noticer (term f p) ' |(P ?X) -3-UNIFIER | ...) 
(push '(add-hashcons-noticer ...) 
♦temp-init-forms*)) 
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^^ (progn 'compile 

f (defun |(P ?X)-UNIFIER| (term) 

• • • ) 

(defun |(P ?X)-B0DY| (?x) 

• • . ) 

(defun |(P ?X)-2-UNIFIER| (term) 

(defun |(P ?X)~2-B0DY| (?x) 
(defun |(P ?X)-3-UNIFIER| (term) 
(defun |(P ?X)-3-B0DY| (?x) 

In spite of the function naming convention exemplified above naming conflicts can occur when two 
demon defining files share a trigger pattern and at least one of the files is compiled. Specifically when a 
compiled file is loaded the names of the functions defined by that file are the names given at compile time 
rather the names which would have been generated had the demon definitions been macroexpanded at load 
time. Consider a compiled file containing a definition for die function |(P ?X)-BODY|. If such a file is loaded 
into a RUP environment which already has a definition for |(P ?X)-BODY| a naming conflict will occur. It is 
also important to note that since loading a compiled file docs not induce macro expansions it also does not 
effect the names generated by later macro expansions. The best policy is to make sure that no two files share 
noticer patterns. 
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6.3. Events 

There are several meaningful event keywords other than : intern. These event keywords are described 
below. 



:true 



Demons defined using this keyword are triggered whenever the TMS node associated 'with 
a term matching the given pattern becomes true. The following example demonstrates the use 
of this function. 

(notice (:true (p ?x)) *user-queue* 
(Iconst (-> (p ?x) (q ?x)))) 

(include-end-forms) 
This macroexpands to : 
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j**\ (progn (add-hashcons-noticer (term 'p) *|(P ?X)-UNIFIER| *user-queue*) 

(push '(add-hashcons-noticer (term 'p) *|(P ?X)-UNIFIER| *user-queue*) 
*temp-init-forms*) ) 

(progn 'compile 

(defun |(P ?X)-UNIFIER| (term) 
(let ((args (cdr subterms))) 
( if args 

(let ((?x (car args))) 
(if (null (cdr args)) 

(|(P ?X)-B0DY| ter;n ?x)))))) 

(defun |(P ?X)-B0DY| (term ?*) 

(if (not (eq *:true (truth (virt-tms-node term)))) 
(push (cons *user-queue* 

*(|(P ?X)-B0DY| .term t ?x)) 
(true-noticers (virt-tms-node term))) 
(add-clause (list (cons (virt-tms-node 

(term-hashcons (list (term *p) ?x))) 
•rfalse) 
(cons (virt-tms-node 

(term-hashcons (list (term *q) ?x))) 
-true)))))) 

Note that the code for |(P?X)-BODY| first checks to see if tlie tms node associated with 
triggering term is true. If it is not then a call to |(P ?X)-BODY| is placed on the true-noticers of 
the node associated with the triggering term. Note that since a node can become true and then 
unknown before its true-noticers are run |(P ?X)-BODY| might be run several times before it is 
run in an environment in which the node associated with the triggering term is true. 

:false 

This keyword is just like :true except that the demon is queued when the node associated 
with the triggering term becomes false rather than true. 



:change 



This keyword causes the demon to be queued the first time die truth of the node associated 
with the triggering term changes. 



:whcnever-true 



f m ^\ 



This keyword causes the body of the demon to be run whenever the node associated with 
the triggering term becomes true. For example the following 

(notice ( :whenever-true (trouble ?x)) *user-queue* 
(trouble-fixer ?x)) 

( incl ude-end-f orms) 
Gives rise to the following definition: 
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y**s (defun [(TROUBLE ?X)-B0DY| (term ?x) 

(push (cons *user-queue* 

• (KTROUBLE ?X)-BODY| ,term ,?x)) 
(true-noticers (virt-tms-node term))) 
(if (eq ':true (truth (virt-tms-node term))) 
(trouble-fixer ?x))) 

rwhcncvcrfalse 

This is the dual of :whenevcr-true. 

^vhcncvcr-change 

This causes the body of die demon to be run every time the tms node associated with the 
triggering term changes its truth state. 

6.4. List Variables 

It is often desirable to be able to write demons which trigger on terms with an arbitrary number of top 
level arguments. A mechanism for doing this exists and is exemplified by the following definition of a noticer 
for list. 

/f^S (notice (:intern (list . largs)) *user-queue* 

(let ((?first (car largs))) 
(Iconst (-> list-definition 

(« (first (list . iargs)) Tfirst)))) 
(if (cdr largs) 

(let (( Irest (cdr largs))) 
(Iconst (-> list-definition 

(■ (tail (list . Iargs)) (list . Irest))))))) 

A Symbol starting with "!" is interpreted as a variable in a noticer trigger pattern and differs from a 
symbol storting with "? M only in that it is bound to a list of terms rather than a single term. An error is 
triggered if either "?" or "!" variables are used in a syntactically incorrect manner. 

6.5. Some Useful Macros 

This section describes some macros which can be used in conjunction with notice, 
nlet 

The macro nlet is just like the macro let except that it expands notice forms which appear 
in its body and allows those notice forms to inherit variables bound by the nlet. notice forms can 
only inherit variables bound by surrounding notice and nlet contexts. The following is an 
example of the use of nlet: 
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/**\ (notice (:intern (f . !args)) *user-queue* 

(nlet ((?first (car largs))) 

(notice (:true (r ?first ?other-thing) ) *user-queue* 
(let (( lother-args (cons ?other-thing (cdr largs)))) 
(Iconst (-> (r Tfirst ?other-thing) 

(■ (f . largs) (f . lother-args)))))))) 



^**\ 



self 



This macro of no arguments is used inside the body of a notice form. An application of self 
macroexpands to a form which evaluates to a form which can be placed on a queue and is in fact 
the current invocation of the body of the innermost demon. Consider the following example: 

(notice (:true (p ?x)) *user-queue* 

(nlet ((nl ( virt-tms-node (termq (p ?x))))) 
(notice (:true (q ?x)) *user-queue* 
(if (not (true? nl)) 

(push (cons *user-queue* (self)) 

( true-noticers nl)) 
(let ((n2 virt-tms-node (termq (p ?x)))) 
(if (not (true? n2)) 
(push (cons *user-queue* (self)) 

(true-noticers n2)) 
(print *((p t (term-tree ?x)) 

and *(q , (term-tree ?x)) 
are both true)))))))) 

Note that the print statement will only be reached in an RUP environment where both the 
nodes associated with the triggering terms arc tnic. Tf the body of the inner noticer is run in an 
environment where the node associated with the first triggering term is false (which can happen) 
then an execution of the body is requeued. The macro self creates a new invocation of the 
innermost notice body with the current binding environment. During subsequent invocations of 
this body either node may be false and the body continues to requeue itself until it is invoked 
when both nodes are true. 



this-noticer 



The macro this-noticer of no arguments macroexpands to a form which evaluates to the 
intern noticer placed on an operator term by the innermost notice form containing this macro. 
This allows one to get access to the noticer and remove it once it has fired. Consider the 
following example: 

(notice (:true (p ?x)) *user-queue* 

(notice (:true (r ?x ?y)) *user-queue* 
(setf (intern-noticers (term *r)) 

(delete (this-noticer) (intern-noticers (term *r)))) 

The above code might be used when it is known that for any ?x there is at most one ?y such 
that (r ?x ?y). Thus when a term triggers the inner demon the intern noticer placed on r can be 
removed thus saving a unification attempts each time some new application of r is interned. 



^s 
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There are cleaner ways to gain efficiency than removing noticers. The section on currying 
is important for anyone worried about efficiency in demonic triggering. 

miipfetch ((var pattern) &rcst body- forms) 

This macro allows one to access exactly those currently interned terms which match a given 
pattern. For each such term the body forms are evaluated sequentially in ar environment in 
which the variable var is bound to the matching term and all of die variables in the pattern are 
bound to the terms resulting from the match, mapfctch returns a list of the values given by the 
last body form. The fact that the pattern is known at macrocxpansion time allows die unification 
process to be open coded as it is in the functions created by notice. Consider the following 
example: 

(mapfetch (uterm (p ?x (f ?y))) 
(cons uterm 

(list (cons '?x ?x) (cons *?y ?y)))) 

This evaluates to a list of pairs each of which is a pair of a term and a binding list where 
each binding list is a list of pairs of a variable and its associated value, mapfetch can inherit 
variable bindings from surrounding notice and nlet forms as is shown in the following example. 

(notice (:true (p ?x)) *user-nueue* 
(putprop (term-plist ?x) 

(mapfetch (uterm (r ?x ?y)) 

?y) 

'r-relations) ) 
The body function defined by this noticer would be as follows: 

(defun |(P ?X)-BODY| (?x) 
(putprop (term-plist ?x) 
(del-if 'null 

(mapcar '(lambda (uterm) 

(let ((args (cdr (subterms uterm)))) 
(if args 

(if (eq ?x (car args)) 
(if (cdr args) 

(let ((?y (cadr args))) 
(if (null (eddr args)) 

?y))))))) 

(applications (term *r)))) 
'r-relations)) 
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^ ms - An alternative to the above is: 

(defmacro r-relations (term) 

(get (term-plist term) 'r-relations)) 

(notice (:true (p ?x)) *r-queue* 

(notice ( :whenever-change (r ?x ?y)) *r-queue* 
(if (true? (virt-tms-node (termq (r ?x ?y)))) 
(if (not (memq ?y (r-relations ?x))) 

(push ?y (r-relations ?x))) 
(setf (r-relations ?x) 

(delete 7y (r-relaticns ?x)))))) 

The above code ensures that if *r-qucue* is empty die for each ?x such that (p ?x) is true 
(r- relations ?x) is a list of exactly those terms ?y such that (r ?x ?y) is true. 

6.6. Currying 

This section describes a technique for writing more efficient demons. The basic idea is that when one 
has a trigger pattern of the form (p tl ?x t2) where ?x is a variable and tl and t2 are known terms one can 
replace that trigger pattern by a pattern of the form (op ?x) where op is a known term incorporating p, tl, and 
t2. In this way the unification function is not applied to all applications of p but is instead only applied to a 
select set of terms which contain the known subtcrms tl and t2. 

There are some conventions adopted in RUP for making this type of transformation more convenient. 
Specifically there is a special higher order operator called curry which takes any number of arguments the first 
of which is always an operator and the remainder of which are cither the number 1 or the number 2. Each of 
the numeric arguments to curry corresponds to an argument of the operator argument to curry. The best way 
to describe curry is with some examples. For any binary operator ?r, diree place operator ?f, and terms ?x ?y 
and ?z we have the following equivalences: 

(?r 7x ?y) - (((curry ?r 1 2) ?x) ?y) 
- (((curry ?r 2 1) ?y) ?x) 

(?f ?x ?y ?z) - (((curry ?f 1 1 2) ?x 7y) ?z) 

* (((curry ?f 1 2 1) ?x ?z) ?y) 

- (((curry ?f 2 1 1) ?y ?z) ?x) 

- (((curry ?f 1 2 2) ?x) ?y ?z) 
■ (((curry ?f 2 1 2) ?y) ?x ?z) 

* (((curry ?f 2 2 1) ?z) ?x ?y) 

The above equivalences are enforced by a collection of demons which could have been defined using 
notice as follows: 

(notice (:intern (curry ?f 2 1 2)) *rup-top-levet* 

(notice (:intern (?f ?x ?y ?z)) Tup-top-level* 

(Tconst (■ (?f ?x ?y ?z) 

(((curry ?f 2 1 2) ?y) ?x 7z))))) 

These demons are only triggered when curry is used so there is no overhead for users who do not use 
currying. However if currying is ever used in writing efficient noticers the above demons ensure that the 
correctly curried versions of the appropriate assertions are always created. The curry demons are hand coded 
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,/**^ for maximal efficiency. 

The following example illustrates the use of currying for efficiency. 

(notice (:true (transitive ?r)) *rup-top-level* 
(notice (:intern (?r ?x ?y)) *rup-top-level* 

(notice (:intern (((curry ?r 1 2) ?y) ?z)) *rup-top-level* 
(Iconst (-> (and (transitive ?r) 
(?r 7x ?y) 

(((curry ?r 1 2) ?y) ?z)) 
(((curry ?r 1 2) ?x) ?z)))))) 

Note that while all uncurried forms aie equated with their curried equivalents the curried forms are not 
necessarily equated with their uncurried equivalents. Thus interning the term (r a b) will trigger an intern 
demon whose pattern is ({(curry r 1 2) ?x) ?y) but interning the term (((curry r 1 2) ?x) ?y) will not trigger an 
intern demon whose trigger pattern is (r ?x ?y). This fact can be important to writing efficient demons (and is 
in fact important in the above example). 

The function term-tree recognizes curried forms and imcurrics them which makes them much more 
readable. 

6.7. Redundancy and Completeness 

There are some problems with the pattern directed demonic invocation mechanisms described in this 
j*~\ section. These problems relate both to the redundant triggering of demons (triggering a demon more often 

than need be) and to the completeness of triggering (not triggering demons when they should be triggered). 
Consider die following demon for pair. 

(notice (:intern (pair ?a (list . Irest))) *user-queue* 
(Iconst .(-> list-definition 

(= (pair ?a (1 ist . 1 rest)) 
(list ?a . Irest)))) 

Suppose the term (pair a (list b c)) has been interned and that the above demon has been triggered on 
this term. Further suppose that the equality (= a 'nil) is true. Some process may create the term 
(pair 'nil (list b c)) as the result of substituting 'nil for a in (pair a (list b c)). If the above demon has been 
triggered on (pair a (list b c)) then there is no reason to trigger it on (pair 'nil (list b c)) since these two terms 
can be equated by substitution. However when the latter term is interned the above intern demon would be 
triggered. 

The result of matching a demon pattern against a particular term is a binding environment e which maps 
the variables in the pattern to terms. In general two binding environments e^ and e 2 will be called variants of 
each otiier if they are defined on the same domain of variables and for each variable ?x in that domain ei(?x) 
and e 2 (?x) are in the same RUP equivalence class. In general a specific invocation of a demon under a binding 
environment e will be called redundant if that demon has already been run under a binding environment 
which is a variant of e. RUP attempts to avoid executing redundant demon invocations by not triggering 
demons with terms which are generated internally via the substitution of equals for equals. Unfortunately 
there are cases in which it is useful to run redundant invocations of a demon. For example consider the 
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/"■^ following: 
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(notice (:intern (cons ?a ?b)) *user-queue* 
(if (and (eq 'quote (car (subterms ?a))) 
(eq 'quote (car (subterms ?b)))) 
(let ((?qterm (term '(quote ,(cons (cadr (subterms ?a)) 
(cadr (subterms 7b))))))) 
(Iconst (-> cons-definition 

(- (cons ?a ?b) ?qterm)))))) 

Clearly the demon has an important effect when run under a binding environment e which binds the 
variables to quotations even if the demon has previously been am on a variant of e which did not bind the 
variables to quotations. The reason the redundant invocation is useful in this case is that the body of the 
demon tests for syntactic properties of the terms to which the variables arc bound. If the body of a demon 
only uses variables in "semantic" ways then this problem would not arise. A variable is used in a semantic 
way when it docs not matter what term die variable is bound to as long as that term refers to die proper tiling. 

One possible extension to the existing demonic mechanisms which might solve the problems related to 
redundant triggering is to introduce a new kind of variable into die patterns of demons which would only 
bind to self-referential terms. This would allow the syntactic tests made in die above demon to be 
incorporated into flic pattern match and thus one might be able to automatically control demonic invocation 
in a way that avoids redundant invocations yet still invokes syntactic demons with the proper binding 
environments. 

In addition to having problems with redundant invocations RUP has a problem in that the demonic 
invocation mechanism is not complete. Consider die following demon: 

(notice (: intern (f (g 7x))) *user-queue* 
(Iconst (-> f-g-def ini tions 

(■ (f (g ?*)) ?*)))) 

Suppose that the term (f b) has been interned and that b and (g c) are in die same equivalence class. By 
substitution it would be possible to generate the term (f (g c)) and the above demon could trigger on this term. 
However since such substitutions are not performed automatically the above demon would not be triggered in 
diiscase. 

For any expression p containing variables (i.e. any trigger pattern) and any substitution e for the 
variables in p let e(p) denote the result of replacing each variable in p by its image under e. Let T be any 
collection of terms and p be any trigger pattern. A substitution e will be said to map p into T just in case e(p) 
is equivalent (can be equated via substitution of equals for equals) to some term in T. Let {pj} be a collection 
of trigger patterns each of which is associated with a body bj. A particular demonic invocation mechanism will 
be said to be complete with respect to {p^ and T just in case for every pj and every binding context e which 
maps pj into T the body bj gets called under some binding context which is a variant of e. 

It should be possible to extend the demonic invocation mechanism in RUP so that it is complete with 
respect to the intern demons and the interned terms, the true demons and the true terms, etc. If the demonic 
invocation mechanism were also careful not to perform redundant invocations such an extension to 
completeness would probably not generate an unreasonable number of demon invocations. 
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f*^- The problem of generating a complete unification mechanism has been studied in detail by people 

working on resolution theorem proving. The problem is defined precisely by Huet and Oppen in a survey of 
results on equations and rewrite rules [Huet & Oppen 79]. 

6.8. Transitive Relations 

There arc true noticers defined in the default RUP environment which recognize applications of the 
second order predicates transitive, reflexhe, antisymmetric and strictly-antisymmetric. Assuming that the 
queues *cqua!ity-invariants*, *rup-top-level*, and ^backtracking-invariant* have all been emptied the 
following conditions hold with regard to these predicates: 

(1) If an asscrtional term of the form (transitive r) is true then all applications of r which can be deduced 
from transitivity and known applications of r have been deduced. 

(2) If an assertion of the form (reflexive r) is true then for each interned term of the form (r x y) if x and y are 
in the same equivalence class then (r x y) is true. 
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(3) If an assertion of the form (antisymmetric r) is true then for each pair of true assertions (r x y) and (r y x) 
the assertion (= x y) is true. 

(4) If an assertion of the form (strictly-antisymmetric r) is true then for each true assertion (r x y) the 
assertion (r y x) is false. 
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*atomic-level* 28 

*backtracker* . 12 

*backtracking-invariant* 12,12 

*basic-queues* ,. „. 6 

*equality-invariants* ...............26 

*intern-canonicalize* ........................22 
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*min-ccrt* 14 

*new-term* 23 
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*premisc-selector*..., ...16 

*smaller?*... ...28 

*subtcrm-level* ........28 
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->noticer 30 

ichange... ... ; 41 

^ x : false 41 

:true... 40 

rwhenever-change.... , ......42 

: whenever- false. ...........42 

: whenever- true . 41 

= -noticer 30 

add-clause 13 

add-hashcons-noticer ................24 

and-noticer .......31 

antisymetric .48 

applications... 24 

assert.... .30 

assertion ., ....7 

assertq 34 

associative?..................... ........23 

atomic-level-default 29 

atomic-level-prop..... ........29 

atomic? 21 

^s backtracker-default .. 16 
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equatcd-support 25 

equivalents.................... 26 
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false?.. ....9 

fifo-empty?. ....6 

fifo-push................ .6 

fix-temps... .. .36 

hashcons-noticers ........24 

iff-noticer... ......32 

implies...... , 13 

intern-canonicalize- default ...22 
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mapfetch.. .44 

member-referents 26 
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new-simplification-state 28 

nc w-term -default ......23 

next-canonical.. ...20 

nlet ..42 

node-add-clause 13 

node-extension 8 

node-plist 8 

node-try-to-show 17 

node-why 15 

not-noticer ....31 

notice........... ...........37 

or-noticer 31 

parents 20 
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premises ..16 

psat 9 

remove-default ..14 

retract 30 

retract-premise 14 

retractq 34 

reverse-truth 16 
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mp-init.. 36 

same-image? 25 

sbound.... 29 

self. .43 

self-referential?....... 21 

set-default ....14 

size , .........26 

strictly-antisymetric. ; .48 

subterms 19 



symtric .........48 
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term-extension. 20 
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term-hashcons ......21 

term-ink .....35 

term-plist.......... 20 

tcrm-tms-node 20 

term-tree , ...21 

term! 24 

term2 24 

termq .......33 

this-noticer 43 

tms-node 7 

transitive 48 

true-eq? 25 

true-noticers 18 

true? 9 

truth 7,7 

try-to-show. 33 

try-to-showq .......34 

unknown?...... 9 
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